Track data encryption

ABSTRACT

A method for using a secondary PAN is disclosed. The method includes providing a secondary PAN associated with a primary PAN, where the secondary PAN has at least one end portion that is the same as the primary PAN, but has a middle portion of that is different than the primary PAN.

CROSS-REFERENCES TO RELATED APPLICATIONS

This patent application claims priority to and is a non-provisional ofU.S. Patent Application Nos. 60/815,059, filed on Jun. 19, 2006,60/815,430 filed on Jun. 20, 2006, and 60/884,089, filed on Jan. 9,2007, which are herein incorporated by reference in their entirety forall purposes.

BACKGROUND

In a typical purchase transaction, a consumer may use a portableconsumer device to buy goods or services from a merchant. The consumer'sPAN or primary account number may be stored in a memory on the portableconsumer device. The PAN may be read at a point of sale terminaloperated by a merchant, and the PAN and other information may betransmitted to the issuer of the portable consumer device along withother transaction information such as the amount of the purchase, etc.Once received, the issuer may then decide whether or not the consumer isauthorized or not authorized to conduct the purchase transaction.

In conventional purchase transactions, the PAN is not encrypted when itpasses from the portable consumer device, to the point of sale terminal,and to the issuer. The non-encryption of the PAN is not a major issue inview of current network security and fraud detection mechanisms.However, it would be desirable to add upfront security to existingpayment systems. For example, if the PAN gets intercepted by anunauthorized person during the transmission of the PAN from the point ofsale terminal to the issuer, the unauthorized person could use the PANto make unauthorized purchases. Thus, new ways to provide for securetransmission of the PAN to the issuer or other entity are desirable.

Embodiments of the invention address these and other problemsindividually and collectively.

BRIEF SUMMARY

Embodiments of the invention are directed to methods, systems, andcomputer readable media that can be used to securely deliver a PANassociated with a portable consumer device from a portable consumerdevice, a point of sale terminal, or some other location, to an issuerof the portable consumer device.

The real PAN associated with the consumer and the consumer's portableconsumer device may be referred to as a “primary PAN.” In embodiments ofthe invention, the primary PAN can be changed to a secondary PAN, whichis linked to the primary PAN. At least a portion of the secondary PANmay be changed (e.g., encrypted) before it arrives at the issuer, andthe issuer (or other entity such as a payment processing network) maysubsequently determine the consumer's primary PAN from the receivedsecondary PAN. The secondary PAN may or may not be known to theconsumer.

Advantageously, the secondary PAN can be used to securely transmitprimary PAN information to the issuer. Also, the secondary PAN may beused to authenticate the portable consumer device being used in aparticular transaction. If, for example, the secondary PAN that isreceived by the issuer is not the correct secondary PAN (e.g., theissuer expects to receive the secondary PAN, and not the primary PAN, inTrack 1 or Track 2), then the issuer may conclude that the portableconsumer device being used is not authentic and may thereafter notapprove the payment transaction.

One embodiment of the invention is directed to a method comprisingproviding a secondary PAN associated with a primary PAN, wherein thesecondary PAN has end portions, and at least one end portion (e.g., aBIN or bank identification number end portion) is the same as theprimary PAN. The secondary PAN may also have a middle portion that isdifferent than the primary PAN. Approval or disapproval for a paymenttransaction is received after providing the secondary PAN. This methodmay be performed by any suitable entity including the consumer or themerchant, with or without other entities.

Another embodiment of the invention is directed to a portable consumerdevice comprising a body, and a computer readable medium coupled to thebody. The computer readable medium comprises code for a secondary PANassociated with a primary PAN. The secondary PAN has end portions, andat least one of the end portions is the same as the primary PAN. Amiddle portion of secondary PAN is different than the primary PAN.

Another embodiment of the invention is directed to a computer readablemedium. The computer readable medium comprises code for providing asecondary PAN associated with a primary PAN using a portable consumerdevice. The secondary PAN has end portions, and at least one end portionis the same as the primary PAN. The secondary PAN also has a middleportion that is different than the primary PAN. The computer readablemedium also comprises code for receiving approval or disapproval for apayment transaction after providing the secondary PAN.

Another embodiment of the invention is directed to a method comprisingreceiving an authorization request message associated with atransaction, the authorization request message including a secondary PANassociated with a primary PAN. The secondary PAN has end portions and amiddle portion. At least one of the end portions is the same as theprimary PAN, and at least a middle portion of the secondary PAN isdifferent than the primary PAN. Once the secondary PAN is received, thesecondary PAN is analyzed, and the primary PAN is analyzed afteranalyzing the secondary PAN. After the primary and secondary PANs areanalyzed, an authorization response message is sent. The authorizationresponse message indicates approval or disapproval of the transaction.This method may be performed by one or more entities including anissuer, payment processing network, etc.

Another embodiment of the invention is directed to a computer readablemedium. The computer readable medium comprises code for receiving anauthorization request message associated with a transaction, where theauthorization request message including a secondary PAN associated witha primary PAN. The secondary PAN has end portions, and at least one ofthe end portions is the same as the primary PAN. A middle portion of thesecondary PAN is different than the primary PAN. The computer readablemedium also comprises code for analyzing the secondary PAN, code foranalyzing the primary PAN, and code for sending an authorizationresponse message, wherein the authorization response message indicatesapproval or disapproval of the transaction.

Another embodiment of the invention is directed to a method comprisingproviding a secondary PAN associated with a primary PAN, wherein thesecondary PAN has a location identification data element. The locationidentification data element is the same in both the primary andsecondary PANs, and at least the middle portion of the secondary PAN isdifferent than the primary PAN. The method also includes receivingapproval or disapproval for a payment transaction after providing thesecondary PAN.

These and other embodiments of the invention are described in furtherdetail below, with reference to the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic illustration of data elements in a data trackassociated with a portable consumer device.

FIG. 2 shows a Track 2 data track as read from an MSD (magnetic stripedata) chip card.

FIG. 3 shows a Track 2 data track as read from a magnetic stripe card.

FIG. 4 shows a system according to an embodiment of the invention.

FIG. 5 shows a flowchart illustrating a method according to anembodiment of the invention.

FIGS. 6( a)-6(b) show primary and secondary PANs that can be used in themethod shown in FIG. 5.

FIG. 7 shows a flowchart illustrating another method according to anembodiment of the invention.

FIG. 8 shows a schematic illustration of a secondary PAN.

DETAILED DESCRIPTION

As explained above, a consumer's PAN is not encrypted in conventionalpurchase transactions. While encryption of the entire PAN can becontemplated to enhance security, encrypting the entire PAN may not bepractical under all circumstances. For example, the PAN contains a BINor a bank identification number. The BIN is used to route thetransaction data to the issuer, and the encrypted BIN may not berecognized by the routing and switching infrastructure computers thatroute transaction data to the issuer. If the entire PAN is encrypted,then the BIN would change and this would cause routing problems.Accordingly, any encryption process that is used to encrypt the PANwould preferably do so without negatively impacting the existingpayments infrastructure, and the way that payment transactions arecurrently handled.

There are a number of other restrictions associated with encryptingPANs. For example, in the context of a payment card with a magneticstripe, cardholder account data (including the cardholder's PAN) on themagnetic stripe is encoded on “Track 1” and/or “Track 2” of the magneticstripe. Track 1 (“International Air Transport Association”) stores moreinformation than Track 2, and contains the cardholder's name as well asaccount number and other discretionary data. This track is sometimesused by the airlines when securing reservations with a credit card.Track 2 (“American Banking Association”) is currently most commonlyused. This is the track that is read by ATMs and credit card checkers.The ABA (American Banking Association) designed the specifications ofthis track and all world banks must abide by it. It contains thecardholder's account, encrypted PIN, plus other discretionary data.

Track 1 is 79 characters long and has limited space. Track 2 is atotally numeric field, is 37 characters long, and also has limitedspace. Because of these restrictions, the data that are in Track 1 orTrack 2 are in decimal form. The data cannot be in any other form suchas hexadecimal (except for the cardholder name in track1). This limitsthe ability to encrypt the PAN in Tracks 1 or 2.

FIG. 1 shows a generic schematic diagram representing a generic datatrack associated with a portable consumer device. The illustrated datatrack contains various data fields. As shown in FIG. 1, the data fieldsmay contain a PAN field, an expiration date field, a service code field,a PIN, a CVV (personal identification number card verification value)field, and discretionary data fields. Typical PANs may be between about13-19 digits (e.g., 13, 16, or 19 digits) long, and the PAN data fieldmay be configured to store data of a corresponding size.

FIG. 2 shows a specific example of a Track 2 format as read from an MSD(magnetic stripe data) chip card. As shown, the exemplary Track 2 formatincludes a PAN 390, a separator 392, an expiration date 394, a PVKI (pinverification key indicator) 398, pin verification data 400, a dCVV(dynamic card verification value) 402, an ATC (automatic transactioncounter 404, a contactless indicator 406 in an issuer discretionary datafield or IDD data field, and padding 408.

FIG. 3 shows an exemplary Track 2 data track as read from a magstripe ormagnetic stripe card. In FIG. 3, there is a start sentinel 414, and aseparator 416. The BIN is between the start sentinel 414 and theseparator 416. There is also an end sentinel 418, and a checksum to theright of the end sentinel 420.

The data tracks in FIGS. 1 and 2 are slightly different. The magstripeTrack 2 data track shown in FIG. 3 uses an end sentinel 420, since amagnetic reader head in a point of sale terminal would need to know whento start and stop reading data. By comparison, in the chip card Track 2data track shown in FIG. 2, an end sentinel is not necessary, since thechip in the chip card would output the appropriate amount of data to thepoint of sale terminal.

Another restriction on encrypting a PAN is that the length of PANs mayvary in different countries. For example, PANs may be 13, 16, or 19digits long. Any method and system for encrypting PANs would preferablywork with PANs of varying length.

Another restriction on encrypting a PAN is that the last digit of thePAN is a check digit. It is used to ensure the data integrity of the PANas it is read by the point of sale terminal. A check digit is a digitadded to a number (either at the end or the beginning) that validatesthe authenticity of the number. A simple algorithm is applied to theother digits of the number which yields the check digit. By running thealgorithm, and comparing the value that is determined by the algorithmwith the check digit value at the end of the PAN, one can verify thatall of the digits are correctly read and that they make a validcombination. A commonly used, well known check digit algorithm is acalled a “mod 10” algorithm.

The encryption processes according to embodiments of the invention canbe used despite the above-noted restrictions. Embodiments of theinvention protect the consumer's PAN and can be used with existingpayment verification mechanisms and systems. As will be illustrated infurther detail below, embodiments of the invention can encrypt a PANwithout requiring any major or unexpected changes to the existingpayments infrastructure. Also, embodiments of the invention can also beused with PANs of varying length.

Embodiments of the invention partially “mask” the primary PAN bycreating a secondary PAN that is linked to the primary PAN. In oneembodiment of the invention, a portion of a transmitted PAN is maskedand/or changed by an access device (e.g., a point of sale terminal), aportable consumer device, or the like, before it is received by theissuer during a transaction such as a payment transaction. The portionthat is changed (e.g., encrypted) is preferably the middle portion ofthe PAN. The middle portion may be of any suitable length, but ispreferably between 3 and 9 digits long.

Any suitable encryption process may be used to mask the middle portionof the PAN. For example, embodiments of the invention may use DES(dynamic encryption standard), ECC (elliptical curve cryptography), orAEC (advanced encryption cryptography) processes. Any symmetric orasymmetric cryptographic elements may be used.

There are two end portions (e.g., each 4-6 digits long) on oppositesides of the middle portion of the PAN, and at least one of the endportions remains static during the transaction process. For example, atleast one end portion of the PAN, which includes the BIN or bankidentification number, remains static during the transaction process andat least the middle portion is changed or encrypted. The BIN (or otherlocation identification data element) remains static during thetransaction process so that the PAN and other transaction data can berouted to the issuer. The BIN typically occupies the first six digits ofthe PAN and may be considered a first end portion of the PAN. In otherembodiments, instead of a BIN, the merchant location identifier,financial institution location identifier, or even an IP address couldbe in an end portion of the PAN and may remain static. Any of these mayremain static in the PAN instead of the BIN.

In addition to the first end portion of the PAN including the BIN, theother end portion of the PAN also preferably remains static during thetransaction process. The second end portion of the primary PAN thatremains static preferably includes the last four digits of the primaryPAN. That is, the last four digits of the primary and secondary PANs arethe same.

There are a number of advantages associated with keeping the second endportion of the secondary PAN the same as the primary PAN. As notedabove, the last character of the primary PAN is a check digit or a mod10 calculation to ensure data integrity. It is therefore desirable thatat least this last check digit not be changed so that the point of saleterminal still performs the appropriate check sum verification process.Lastly, the consumer is used to seeing the last four digits of the PANprinted on the consumer's purchase receipts, so it would be desirablenot to change the last four digits of the PAN. In addition, the lastfour digits of the PAN are typically printed on purchase receipts whichare often discarded by consumers, so the last four digits are easilydiscovered. There is therefore little benefit in encrypting the lastfour digits of the primary PAN. Thus, in preferred embodiments of theinvention, the dynamically changing numbers of the PAN are typicallymasked. The last four digits are static on a payment card receipt thatis received by a consumer so that the consumer advantageously does notsee anything unusual.

FIG. 1 shows a system 20 that can be used in an embodiment of theinvention. The system 20 includes a merchant 22 and an acquirer 24associated with the merchant 22. In a typical payment transaction, aconsumer 30 may purchase goods or services at the merchant 22 using aportable consumer device 32. The acquirer 24 can communicate with anissuer 28 via a payment processing network 26.

The acquirer 24 is typically a bank that has a merchant account. Theissuer 28 may also be a bank, but could also be business entity such asa retail store. Some entities are both acquirers and issuers, andembodiments of the invention include such entities.

The consumer 30 may be an individual, or an organization such as abusiness that is capable of purchasing goods or services.

The portable consumer device 32 may be in any suitable form. Forexample, suitable portable consumer devices can be hand-held and compactso that they can fit into a consumer's wallet and/or pocket (e.g.,pocket-sized). They may include smart cards, ordinary credit or debitcards (with a magnetic strip and without a microprocessor), keychaindevices (such as the Speedpass™ commercially available from Exxon-MobilCorp.), etc. Other examples of portable consumer devices includecellular phones, personal digital assistants (PDAs), pagers, paymentcards, security cards, access cards, smart media, transponders, and thelike. The portable consumer devices can also be debit devices (e.g., adebit card), credit devices (e.g., a credit card), or stored valuedevices (e.g., a stored value card).

The portable consumer device 32 may comprise a computer readable medium32(a) and a body 32(b). The computer readable medium 32(a) may be on thebody 32(b), which may in the form a plastic substrate, housing, or otherstructure. If the portable consumer device 32 is in the form of a card,it may have an embossed region 32(c) which is embossed with the primaryPAN.

The computer readable medium 32(a) may be a memory that stores data andmay be in any suitable form. Exemplary computer readable media 32(a) maybe in the form of a magnetic stripe, a memory chip, etc. The computerreadable medium 32(a) may electronically store the primary and/or thesecondary PAN in encrypted or unencrypted form.

The payment processing network 26 may include data processingsubsystems, networks, and operations used to support and deliverauthorization services, exception file services, and clearing andsettlement services. An exemplary payment processing network may includeVisaNet™. Payment processing networks such as VisaNet™ are able toprocess credit card transactions, debit card transactions, and othertypes of commercial transactions. VisaNet™, in particular, includes aVIP system (Visa Integrated Payments system) which processesauthorization requests and a Base II system which performs clearing andsettlement services.

The payment processing network 26 may include a server computer. Aserver computer is typically a powerful computer or cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server. The payment processing network 26 may use any suitable wiredor wireless network, including the Internet.

The merchant 22 may also have, or may receive communications from, anaccess device 34 that can interact with the portable consumer device 32.In FIG. 4, the access device 34 is located at the merchant 22. However,it could be located at any other suitable location in other embodimentsof the invention.

The access devices according to embodiments of the invention can be inany suitable form. Examples of access devices include point of sale(POS) devices, cellular phones, PDAs, personal computers (PCs), tabletPCs, handheld specialized readers, set-top boxes, electronic cashregisters (ECRs), automated teller machines (ATMs), virtual cashregisters (VCRs), kiosks, security systems, access systems, and thelike.

The access device 34 may include a reader 34(a), a processor 34(b) and acomputer readable medium 34(c). The reader 34(b) may use any suitablecontact or contactless mode of operation. For example, exemplary cardreaders can include RF (radio frequency) antennas, magnetic stripereaders, etc. to interact with the portable consumer device 32.

In a typical purchase transaction, the consumer 30 purchases a good orservice at the merchant 22 using a portable consumer device 32 such as acredit card. The consumer's portable consumer device 32 can interactwith an access device 34 such as a POS (point of sale) terminal at themerchant 22. For example, the consumer 30 may take a credit card and mayswipe it through an appropriate slot in the POS terminal. Alternatively,the POS terminal may be a contactless reader, and the portable consumerdevice 32 may be a contactless device such as a contactless card.

An authorization request message is then forwarded to the acquirer 24.After receiving the authorization request message, the authorizationrequest message is then sent to the payment processing network 26. Thepayment processing network 26 then forwards the authorization requestmessage to the issuer 28, or a third party entity acting on behalf ofthe issuer, of the portable consumer device 32.

After the issuer 28, or a third party entity acting on behalf of theissuer, receives the authorization request message, the issuer 28, orthe third party entity acting on behalf of the issuer, sends anauthorization response message back to the payment processing network 26to indicate whether or not the current transaction is authorized (or notauthorized). The transaction processing network 26 then forwards theauthorization response message back to the acquirer 24. The acquirer 24then sends the response message back to the merchant 22.

After the merchant 22 receives the authorization response message, theaccess device 34 at the merchant 22 may then provide the authorizationresponse message for the consumer 30. The response message may bedisplayed by the access device 34, or may be printed out on a receipt.

At the end of the day, a normal clearing and settlement process can beconducted by the transaction processing network 26. A clearing processis a process of exchanging financial details between and acquirer and anissuer to facilitate posting to a consumer's account and reconciliationof the consumer's settlement position.

Embodiments of the invention can utilize secondary PANs in theabove-described payment transaction processes. Such embodiments aredescribed below with reference to FIGS. 4-8.

An encryption method according to one embodiment of the invention may bedescribed with reference to FIGS. 4, 5 and 6(a)-6(b).

In an exemplary embodiment, a consumer 30 uses his portable consumerdevice 32 to pay for goods or services offered by the merchant 22. Theconsumer 30 takes the portable consumer device 32 and uses it tointeract with the reader 34(a) in the access device 34 as describedabove. The primary PAN may be stored in the computer readable medium32(a).

The access device 34 can then receive the primary PAN from the portableconsumer device 32 (step 502). The primary PAN may be received from theportable consumer device 32 using any suitable contact or contactlessmode of operation.

Once the processor 34(b) in the access device 34 receives the primaryPAN, it can take the primary PAN and can change the middle portion ofthe PAN, while at least one end portion remains static to produce asecondary PAN (step 504). Preferably, both end portions including theBIN and the last four digits of the PAN are the same in both the primaryand secondary PANs. For example, FIG. 6( a) shows an exemplary primaryPAN which is “4592341234563337.” The first six digits “459234” representthe BIN, may be a first end portion, and are static (i.e., the first sixdigits are the same in both the primary and secondary PANs) during thetransaction process. The last four digits “3337” may constitute a secondend portion and may also remain static (i.e., the last four digits arethe same in both the primary and secondary PANs) during the transactionprocess. In this example, the first end portion of the secondary PAN (orthe primary PAN) includes six digits while the second end portionincludes four digits. In other embodiments, the first and second endportions, and the middle portion, may include more or less digits.

While the first and second end portions remain static, at least amajority of the digits in the middle portion are changed. Preferably, atleast 3, 4, or 5 digits in the middle portion, all of the digits in themiddle portion, or all of the digits except for one digit in the middleportion, are changed so that they are all the same. For example, asshown in FIG. 6( b), the middle six digits are “zeroed” out in asecondary PAN. By doing this, the issuer can be assured that the formedsecondary PAN is not the same as a primary PAN that is associated withanother consumer. After the issuer receives the secondary PAN, theissuer would recognize that there is no account number with six zeros inthe middle, and the issuer would then locate the primary PAN at anotherlocation (as described in further detail below).

In some embodiments, all digits in the middle portion of the secondaryPAN are the same, except for one digit. The one digit that is not thesame as the other digits may be adjusted so that when a checksumcalculation is performed on the secondary PAN, it will match thechecksum digit in the primary PAN (i.e., the last digit of the PAN). Forexample, a checksum calculation may result in “7” for a primary PAN andthe number “7” may be at the end of the primary PAN. If all digits inthe middle portion of the primary PAN are changed to “0” to form asecondary PAN, this may result in a different checksum value. Forexample, after replacing the middle portion of the primary PAN withzeros, the checksum value may be different than “7”. However, to “trick”the access device 22 into thinking that the correct PAN has beenreceived, one digit in the middle portion of the PAN may be changed to anumber other than zero so that the result of the checksum calculation isthe proper one. For example, referring to FIG. 6( b), the middle portionof the secondary PAN may be changed to “000900.” The addition of thenumber “9” to the middle portion may cause a checksum calculation toproduce the same result (e.g., “7”) as the checksum digit associatedwith an unaltered primary PAN (e.g., “7”).

After the secondary PAN is created, the processor 34(b) then stores thesecondary PAN in a location where the primary PAN is normally located(e.g., Track 2). The processor 34(b) may then encrypt the entire primaryPAN or just a portion of the primary PAN (step 508). The encryptedprimary PAN may then be stored in an area other than the data track fromwhich it came (step 510), or in a location other than where it isnormally stored. For example, if the primary PAN was originally storedin Track 2, then the encrypted primary PAN may be stored in Track 3 orsome other area. The processor 34(b) may perform these and otherfunctions and code for causing the processor 34(b) to perform thesefunctions may be stored in the computer readable medium 34(c).

The access device 34 may then send both the encrypted primary PAN andthe secondary PAN (with or within an authorization request message) tothe issuer 28 via the acquirer 24 and the payment processing network 26(step 512). The issuer 28 may then receive both the encrypted primaryPAN and secondary PAN (step 514).

A server computer 21 at the issuer 28 then analyzes the secondary PAN(step 516), and then checks to see if it matches the account numbers ofany of its customers. Because the middle portion of the secondary PANhas a majority of its digits repeated, or because a valid PAN structureis not present, the server computer 21 at the issuer 28 will recognizethat the secondary PAN does not match of its existing account numbers.Consequently, the server computer 21 can then look to the area where theencrypted primary PAN is stored. The server computer 28 then locates theencrypted primary PAN and then decrypts the primary PAN 518 using a keythat is stored in the database 23. Once the primary PAN 518 isdecrypted, it is analyzed and the portable consumer device 32 isthereafter authenticated. After authenticating the portable consumerdevice 32, the issuer 28 sends the authorization response message backto the merchant 22 indicating whether or not the consumer 30 isauthorized to conduct the transaction.

Although one issuer 28 is shown in FIG. 1, in embodiments of theinvention, there may be many issuers. Each issuer can determine the areawhere the primary PAN is to be stored, if it wants to encrypt theprimary PAN in that stored area, and/or the key that is used to encryptthe primary PAN. If different issuers use different protocols forstoring and processing the primary PAN, then the risk of widespreadfraudulent activity is reduced. For example, if the data that is beingtransmitted from the merchant 22 to the issuer 28 is intercepted by anunauthorized person, and if the unauthorized person is even capable ofdetermining where the encrypted primary PAN is stored and how to decryptthe transmitted data, the unauthorized person would not be able to usethis information to intercept and decrypt PAN information passing toother issuers, since the other issuers would be using a different dataprotection protocol than the issuer 28.

In the above described example, the secondary PAN is created at theaccess device 34. Thus, data transmission is very secure between theaccess device 34 and the issuer 28. However, the secondary PAN couldalso be generated at any other suitable location. For example, toprovide even more security, the portable consumer device 32 couldprovide both the primary and second PANs to the access device 34 so thatthe access device 34 does not perform any data conversions or encryptionof the primary PAN. The secondary PAN may be stored statically on thecomputer readable medium 32(a) of the portable consumer device 32, ormay be dynamically generated by the portable consumer device 32 if theportable consumer device 30 is a smart card or the like. In suchembodiments, the secure transmission of the primary PAN can be providedfrom the portable consumer device 32 to the issuer 28 to authenticatethe portable consumer device 32.

Other embodiments of the invention can be described with reference toFIGS. 4, 7 and 8.

FIG. 7 shows a flowchart illustrating an embodiment of the invention. Asin the previously described embodiments, in this embodiment, a consumer30 uses his portable consumer device 32 to pay for goods or servicesoffered by the merchant 22. The consumer 30 takes the portable consumerdevice 32 and uses it to interact with the reader 34(a) in the accessdevice 34. The primary PAN may be stored in the computer readable medium32(b).

The access device 34 then receives the primary PAN from the portableconsumer device 32 (step 602). The primary PAN may be received from theportable consumer device 32 using any suitable contact or contactlessmode of operation.

Once the processor 34(b) in the access device 34 receives the primaryPAN, it can take the primary PAN and can change the middle portion ofthe PAN, while at least one end portion remains static, to produce asecondary PAN (step 604). For example, FIG. 8 shows a schematicillustration of a 16 digit PAN 380 that might reside in the computerreadable medium 32(a) (e.g., a magnetic stripe) in the portable consumerdevice 32. In this example, the first six digits (i.e., a first endportion) “123456” 380(a) of the PAN 380 would correspond to the BINnumber. The next 6 digits 380(b) may be changed or different from thereal PAN's 6 digits and are represented by “XXXXXX” in this example. Ina preferred embodiment, the middle six digits may be dynamically changedusing a counter or the like. This makes it more difficult for anyunauthorized person to determine the primary PAN.

The last four digits 380(c) (i.e., a second end portion) are “9999” inthis example, and would remain the same. By keeping the BIN and the lastfour digits the same, the transaction will look like a real one to themerchant and the consumer.

In this embodiment, the middle portion does not intentionally containrepeating numerical values, so the issuer 28 may take steps to ensurethat the secondary PAN does not match or overlap with the primary PANsof other customers. For example, the issuer may set aside a set ofnumbers specifically reserved for secondary PANs, and not primary PANs.

The access device 34 then optionally encrypts the secondary PAN (step608) and sends the encrypted secondary PAN to the issuer 28 via theacquirer 24 and the payment processing network 26 (step 610). The issuer28 then receives the encrypted secondary PAN (step 614), decrypts it(step 616), determines the primary PAN, and then analyzes it (step 618).An appropriate algorithm or look-up table (e.g., stored in the database23) at the issuer 28 may be used to link the primary and secondary PANs.After the issuer 28 determines the primary PAN, the issuer 28 may thenauthenticate the portable consumer device 32 (step 620). The issuer 28thereafter sends an authorization response message back to the merchant22 via the payment processing network 26 and the acquirer 24 indicatingwhether or not the transaction is authorized or approved (step 622).

In many of the specific embodiments described above, a secondary PANand/or primary PAN is encrypted by an access device 34, a portableconsumer device 32, or the like. The encrypted secondary PAN and/orprimary PAN is received at the issuer 28 and the issuer 28 may thendecrypt the secondary PAN and/or the primary PAN to authenticate theportable consumer device 32 and process the payment transaction. It isunderstood, however, that in other embodiments of the invention, thedecryption process may occur at the payment processing network 26,before the PANs arrive at the issuer 28 in a similar manner as describedabove. For example, after the primary PAN and/or secondary PAN aredecrypted by the payment processing network 26, the payment transactionprocess can proceed as it normally does. That is, the payment processingnetwork 26 can receive the encrypted primary PAN and/or secondary PAN,decrypt them, verify that the portable consumer device 32 is authentic,and then reformat the authorization request message in a normal formatso that the decrypted primary PAN is located in an area where it isnormally located. After the authorization request message isreformatted, it can be sent to the issuer 28 as it would be sent in aconventional manner. The issuer 28 can then send the payment processingnetwork 26 an authorization response message, and the payment processingnetwork 26 may in turn send it back to the access device 34 via theacquirer 24 and the merchant 22. Such embodiments are advantageous,since security is enhanced compared to conventional payment processes,yet the issuer 28 will see the same transaction information that itnormally sees in conventional payment processes.

Also, in many of the embodiments described above, the secondary PAN isgenerated during the transaction process. This is not necessary in allcases. Instead of generating the secondary PAN at the access device 34,the secondary PAN may be stored in the computer readable medium of theportable consumer device and it may have a middle portion that isdifferent than the middle portion of the primary PAN. In suchembodiments, the secondary PAN may not be generated during theparticular transaction being conducted, but may have been previouslygenerated and stored on the portable consumer device 32. In some cases,the primary PAN and may be embossed on the portable consumer device 32if the portable consumer device 32 is in the form of a payment card, andthe secondary PAN may be stored in the computer readable medium 32(a) inthe portable consumer device 32.

As illustrated above, in some embodiments, both the primary PAN and thesecondary PAN may be transmitted to the issuer to verify that theportable consumer device being used is authentic. If an unauthorizedperson tries to use the primary PAN, then that unauthorized person willnot know the secondary PAN and cannot fraudulently conduct a purchasetransaction without knowing the secondary PAN. Alternatively, if anunauthorized person electronically intercepts or “skims” the secondaryPAN, then the unauthorized person will not be able to conduct thepurchase transaction without knowing the primary PAN.

In yet other embodiments, as noted above, the middle portion of the PANmay be changed dynamically. For example, an appropriate algorithm orcounter may be used to dynamically change the middle portion of the PANeach time the portable consumer device is used. This way, even if theprimary PAN is electronically intercepted by an unauthorized person, andthe unauthorized person knows the primary PAN, the secondary PAN will bedynamically changing. Even if the unauthorized person knows the primaryPAN and intercepts the secondary PAN once, the intercepted secondary PANwould be useless, since it is a dynamically changing secondary PAN. Inthis case, the unauthorized person would need to know the algorithm usedto dynamically change the PAN in addition to the primary PAN, thesecondary PAN and potentially any keys that are required for theencryption or secondary PAN derivation process. Thus, this embodiment isparticularly useful for conducting secure transactions.

Embodiments of the invention can have one or more of the followingadvantages. First, there are no major impacts on the terminal side.Second, routing is preserved and is not impacted. Third, encryptioncould be card based or terminal based encryption. Fourth, there are noimpacts on the receipt printing and the card holder experience. Fifth,there are no impacts on issuer processing as the issuer is receiving theclear unencrypted data (if the primary PAN is decrypted before itreaches the issuer). Sixth, embodiments of the invention take advantageof pre-existing data delivery fields and standard, publicly availableand proven encryption methods and algorithms (e.g., the symmetric TripleDES algorithm). Seventh, embodiments of the invention would need onlyminor system updates on the acquirer side and would use fields that arecurrently well defined and understood. Eighth, since the data areencrypted, embodiments of the invention can be used against certaincounterfeit attacks rendering it difficult to use data obtained at aface to face merchant, mail order, telephone, or Internet basedenvironments. As the data could be encrypted and dynamic, embodiments ofthe invention can help defend against fraudulent attacks on themerchants' databases as the data is rendered useless.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using computer softwarein a modular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will know andappreciate other ways and/or methods to implement the present inventionusing hardware and a combination of hardware and software

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer readable medium, such as a random accessmemory (RAM), a read only memory (ROM), a magnetic medium such as ahard-drive or a floppy disk, or an optical medium such as a CD-ROM. Anysuch computer readable medium may reside on or within a singlecomputational apparatus, and may be present on or within differentcomputational apparatuses within a system or network.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the invention.

A recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

1. A method comprising: receiving an authorization request messageassociated with a transaction at a server computer, the authorizationrequest message including a secondary PAN associated with a primary PANcomprising a primary PAN first end portion consisting of a six digitbank identification number, a primary PAN second end portion consistingof four digits, and a primary PAN middle portion, comprising at leastthree digits, between the primary PAN first end portion and the primaryPAN second end portion, wherein the secondary PAN has a secondary PANfirst end portion consisting of the six digit bank identificationnumber, a secondary PAN second end portion comprising the four digits ofthe primary PAN second end portion, and a secondary PAN middle portionthat is different from the primary PAN middle portion, wherein thesecondary PAN middle portion comprises at least three digits that areidentical and wherein the secondary PAN is in a PAN field in theauthorization request message; analyzing the secondary PAN by the servercomputer and determining that the secondary PAN comprises the at leastthree digits that are identical and that the secondary PAN is not a realprimary account number; based on the determining that the secondary PANcomprises the at least three digits that are identical, obtaining theprimary PAN by the server computer from a location in the authorizationrequest message other than the PAN field; analyzing the primary PAN bythe server computer; and sending an authorization response message bythe server computer, wherein the authorization response messageindicates approval or disapproval of the transaction, wherein both theprimary PAN and the secondary PAN are either 13, 16, or 19 digits long.2. The method of claim 1, wherein the primary PAN is associated with aportable consumer device, and wherein the method is performed by anissuer or a payment processing network.
 3. A computer readable storagemedium having a computer readable code embodied therein, said computerreadable code when executed by a processor causes the processor toperform a method comprising: receiving an authorization request messageassociated with a transaction, the authorization request messageincluding a secondary PAN associated with a primary PAN comprising aprimary PAN first end portion consisting of a bank identificationnumber, a primary PAN second end portion consisting of four digits, anda primary PAN middle portion, comprising at least three digits, betweenthe primary PAN first end portion and the primary PAN second endportion, wherein the secondary PAN has a secondary PAN first end portionconsisting of the bank identification number, a secondary PAN second endportion comprising the four digits of the primary PAN second endportion, and a secondary PAN middle portion that is different from theprimary PAN middle portion, wherein the secondary PAN middle portioncomprises at least three digits that are identical and wherein thesecondary PAN is in a PAN field in the authorization request message;analyzing the secondary PAN and determining that the secondary PANcomprises the at least three digits that are identical and that thesecondary PAN is not a real primary account number; based on thedetermining that the secondary PAN comprises the at least three digitsthat are identical, obtaining the primary PAN from a location in theauthorization request message other than the PAN field; analyzing theprimary PAN; and sending an authorization response message, wherein theauthorization response message indicates approval or disapproval of thetransaction, wherein both the primary PAN and the secondary PAN areeither 13, 16, or 19 digits long.
 4. The computer readable medium ofclaim 3 wherein the method further comprises identifying the bankidentification number and routing the authorization request messagebased on the bank identification number.
 5. A server comprising: aprocessor; and a computer readable storage medium coupled to theprocessor, the computer readable storage medium comprising code, thatwhen executed by the processor, causes the processor to perform a methodcomprising receiving an authorization request message associated with atransaction, the authorization request message including a secondary PANassociated with a primary PAN comprising a primary PAN first end portionconsisting of a bank identification number, a primary PAN second endportion consisting of four digits, and a primary PAN middle portion,comprising at least three digits, between the primary PAN first endportion and the primary PAN second end portion, wherein the secondaryPAN has a secondary PAN first end portion consisting of the bankidentification number, a secondary PAN second end portion comprising thefour digits of the primary PAN second end portion, and a secondary PANmiddle portion that is different from the primary PAN middle portion,wherein the secondary PAN middle portion comprises at least three digitsthat are identical and wherein the secondary PAN is in a PAN field inthe authorization request message; analyzing the secondary PAN anddetermining that the secondary PAN comprises the at least three digitsthat are identical and that the secondary PAN is not a real primaryaccount number; based on determining that the secondary PAN comprisesthe at least three digits that are identical, obtaining the primary PANfrom a location in the authorization request message other than the PANfield; analyzing the primary PAN; and sending an authorization responsemessage, wherein the authorization response message indicates approvalor disapproval of the transaction, wherein both the primary PAN and thesecondary PAN are either 13, 16, or 19 digits long.
 6. The method ofclaim 1, wherein the secondary PAN middle portion comprises encrypteddigits.
 7. The method of claim 6, wherein the encrypted digits aredynamically generated.
 8. The method of claim 1, wherein the secondaryPAN middle portion comprises a number that will cause the secondary PANto produce a checksum value that is the same as that produced by theprimary PAN.
 9. The computer readable medium of claim 3, wherein thesecondary PAN middle portion comprises an encrypted portion.
 10. Thecomputer readable medium of claim 9, wherein the encrypted portion isgenerated dynamically.
 11. The computer readable medium of claim 9,wherein the encrypted portion is statically stored on a portableconsumer device.
 12. The computer readable medium of claim 3, whereinthe secondary PAN middle portion comprises a number that will cause thesecondary PAN to produce a checksum value that is the same as thatproduced by the primary PAN.
 13. The method of claim 1 wherein thesecondary PAN consists of the secondary PAN first end portion, thesecondary PAN second end portion, and the secondary PAN middle portion.14. The method of claim 13 wherein the secondary PAN middle portion hasdigits that are all identical.
 15. The method of claim 13 wherein thesecondary PAN middle portion has digits that are all identical, exceptfor one digit which causes the secondary PAN to produce the samechecksum value as the primary PAN.
 16. The method of claim 1 wherein theauthorization request message comprises an expiration date field, aservice code field, and a card verification value.
 17. The computerreadable medium of claim 3 wherein the authorization request messagecomprises an expiration date field, a service code field, and a cardverification value.
 18. The method of claim 1 further comprising:sending a re-formatted authorization request message to an issuer,wherein the re-formatted authorization request message comprises theprimary PAN.
 19. The method of claim 18 wherein the secondary PAN middleportion has digits that are all identical, except for one digit whichcauses the secondary PAN to produce the same checksum value as theprimary PAN.
 20. The method of claim 19 further comprising, receiving,by an access device, the primary PAN, wherein the authorization requestmessage is received at the server computer from the access device thatgenerates the authorization request message comprising the secondary PANafter the access device receives the primary PAN.
 21. The method ofclaim 1 further comprising, receiving, by an access device, the primaryPAN, wherein the authorization request message is received at the servercomputer from the access device that generates the authorization requestmessage comprising the secondary PAN after the access device receivesthe primary PAN.
 22. The method of claim 1 wherein the secondary PANmiddle portion comprises a number that will cause the secondary PAN toproduce a checksum value that is the same as that produced by theprimary PAN, and wherein the method further comprises: performingchecksum calculations by the server computer on the primary PAN and thesecondary PAN, wherein the calculated checksum values calculated for theprimary and secondary PANs are the same.